Web server

ABSTRACT

A web server ( 1 ) responds to a request message from a remote user device ( 2 ) by dynamically generating web page code capable of being interpreted by the user device. A device type identifier ( 45 ) is extracted from the request message and is input to a code generating engine ( 25 ) which interprets stored instructions for generating the web page code with reference to selected device dependent information corresponding to the device type identifier. The web page information is stored as a content document comprising a set of instructions written in a script language. The web server generates web pages in an appropriate form for each user device without the need to convert web pages from one form to another.

[0001] This invention relates to web servers and in particular but notexclusively to a web server for responding to request messages receivedvia the internet from remote user devices and to a web server capable ofresponding with web page code tailored to meet the capabilities of theremote user device.

[0002] The use of the internet has recently flourished to the extentwhere almost every business concern has its own website to provideinformation and online purchasing facilities. The majority of suchwebsites have in the past been accessed by remote user devices which arePCs (Personal Computers) using one of a relatively small number ofavailable browser applications so that, by and large, the websites wererequired to output web page code in a single format for viewing at theuser device.

[0003] More recently, there has been a proliferation in new internetenabled devices such as PDAs (Personal Digital Assistants), mobiletelephones with WAP (Wireless Application Protocol) facilities, IDTV(Interactive Digital Television), information kiosks, games, consolesand home appliances. The capabilities of these devices vary considerablyfrom device to device, both in their display function in terms of screensize and colour processing ability, bandwidth and available memory aswell as variables associated with communication including image format,communication protocol and markup language.

[0004] In order to enable users of these different devices to accesstheir websites, many businesses have resorted to building separate webservers to serve each device type. This however creates data managementproblems where a customer may wish to have the option of using differentdevices to communicate with the merchant using the same account detailsfor example, the merchant then requiring a proliferation of differentweb server applications to be managed and updated when required with newor additional material.

[0005] An alternative approach has been to provide a separate port of awebsite for access by an alternative type of user device, the separateport obtaining the required web page code by translating the original PCbased web page code, typically in HyperText Markup Language (HTML)format, to other device formats such as Wireless Markup Language (WML)used for WAP telephones. Such solutions however generally have failed todeliver optimum presentation to the user of the device. The translatingprocess (often referred to as “transcoding”) is difficult to engineer.For example, it is necessary to provide appropriate selection ofinformation which is to be omitted from display in the device havinglower capabilities than the PC. This difficulty is compounded when it isnecessary to update the original PC web page code because thetranscoding process must also be reengineered.

[0006] It has also been proposed that the protocols used for accessingweb page information over the internet should be unified by the adoptionof standards in order to overcome problems resulting from remote userdevices having different capabilities. The use of Extensible MarkupLanguage (XML) as a format for web page code has been proposed. XML is amark-up language for defining content and can be used with XSL(Extensible Stylesheets Language) used to transform XML documents withstyle sheets at the point of presentation. As yet however, suchstandards have not been adopted and this solution is not seen as optimumfor all device types.

[0007] The present invention seeks to provide an improved web serverwith multi-channel capabilities able to serve different types of remoteuser device.

[0008] According to the present invention there is disclosed anapparatus for responding to a request message from a remote user devicefor web page information by generating web page code representative ofone or more web pages to be displayed by the user device and outputtinga response message comprising the web page code.

[0009] Preferably the apparatus comprises extracting means forextracting from the request message a device type identifier identifyingthe remote user device as being one of a set of possible device typeshaving different capabilities.

[0010] The apparatus preferably has a processor for operating a codegenerating engine to generate the web page code, first memory means forstoring the web page information as a set of instructions, and secondmemory means for storing device dependent information for each of thedifferent device types for tailoring the web page code to thecapabilities of the device type.

[0011] The code generating engine preferably comprises interpretingmeans for interpreting the instructions with reference to selecteddevice dependent information corresponding to the device typeidentifier, the code generating means thereby being operable to generatethe web page code in a form in which the web page code is tailored tothe capabilities of the remote user device.

[0012] Preferred embodiments of the present invention will now bedescribed by way of example only and with reference to the accompanyingdrawings of which:

[0013]FIG. 1 is a schematic overview of connection between a web serverand remote user devices;

[0014]FIG. 2A is a schematic diagram of the web server of FIG. 1;

[0015]FIG. 2B is a functional diagram for illustrating signal flow inthe web server of FIG. 2A;

[0016]FIG. 3 is a schematic diagram of policy tables for use with theweb server of FIG. 2;

[0017]FIG. 4 is a schematic diagram illustrating operation of the codegenerating engine;

[0018]FIG. 5A illustrates a layout for a PC;

[0019]FIG. 5B illustrates a layout for a television;

[0020]FIG. 5C illustrates a layout for a PDA;

[0021]FIG. 5D illustrates a layout for a WAP telephone;

[0022]FIG. 5E illustrates layout for a device having a large screen;

[0023]FIG. 5F illustrates the display of fragments in a device having asmall screen;

[0024]FIG. 5G illustrates a multi-menu structure in a large screendevice;

[0025]FIG. 5H illustrates the relationship between control segments andcontent segments in the layout of FIG. 5G;

[0026]FIG. 6 illustrates the hierarchy of a device policy table;

[0027]FIG. 7 illustrates schematically the software provided to the webserver;

[0028]FIG. 8 illustrates schematically the hardware required by the webserver;

[0029]FIG. 9 illustrates schematically the separation of content codeand presentation of information for use by the code generating engine;

[0030]FIG. 10 illustrates schematically a system comprising a productionserver and a development server;

[0031]FIG. 11 illustrates the exchange of signals in the system of FIG.10 when a new type of user device is encountered for the first time;

[0032]FIG. 12 illustrates schematically a server having a cache memory;

[0033]FIG. 13 is a flowchart illustrating the method of operation of agateway server of FIG. 12;

[0034]FIG. 14 is a flowchart illustrating operation of a dynamic webpage server of FIG. 12;

[0035]FIG. 15 is a schematic diagram illustrating a component logicsoftware module;

[0036]FIG. 16 is a flowchart illustrating operation of code generationusing the component logic software module;

[0037]FIG. 17 is a diagram illustrating the hierarchy of data objectswhich are different versions of data referenced by a single componentname;

[0038]FIG. 18 illustrates the hierarchy of text objects with differenttext code sizes and languages;

[0039]FIG. 19 illustrates the signal flow in a web server in which panedissection occurs;

[0040]FIG. 20 is a flowchart illustrating pane dissection;

[0041]FIG. 21 illustrates the dissection of a pane into shards;

[0042]FIG. 22 illustrates use of a user session memory during formfilling;

[0043]FIG. 23 illustrates the dissection of a pane used in form filling;

[0044]FIG. 24 illustrates the function of the graphical user interface;and

[0045]FIG. 25 is a flowchart illustrating a method of file storage.

[0046]FIG. 1 illustrates a web server 1 connected to remote user devices2 via the internet 3. The remote user devices are illustrated to be aPC, television, PDA, and a mobile telephone with WAP facility but caninclude any number of different devices with internet capability. Theweb server 1 is provided with a web server GUI (Graphical UserInterface) 4 enabling an operator of the web server to author documentsand generally control and maintain operation of the web server. The webserver 1 is also connected via the internet 3 to a service centre 5which acquires information concerning any new types of user device andprovides the web server 1 with consequential software revision whenrequired.

[0047]FIG. 2A is a simplified schematic diagram of the web server 1 ofFIG. 1. The web server 1 includes a processor 20 which operates a codegenerating engine 21 in the form of an application which is run by theprocessor on demand in order to generate web page code. The codegenerating engine 21 in this embodiment is written in the Javaprogramming language and during operation of the web server exists inthe working memory of the processor 20 in compiled form as byte codesand is implementable within a Java run time environment.

[0048] A memory 22 stores content code 23 which defines web pageinformation in the form of documents written in a mark up language whichin the present example is JSPI. 1 (Java Server Pages). These documentsare typically authored by the operator of the web server 1 using thegraphical user interface 4. The memory 22 also stores operational data24 which includes for example data which may need to be incorporatedinto web page code generated at run time in response to specific queriesoriginating from the user device 2 and data acquired by monitoring usageof the web server. Data objects referenced by the content code 23 arestored in a database 19. These data objects may include files containingimages or text and other forms of data objects which an author may wishto include in the web page code to be generated.

[0049] Device dependent information 25 is also stored in memory 22 andconsists primarily of policy tables described below. The memory 22 alsostores program code 26 which may be accessed by the processor 20 duringoperation of the server 1 or used to retrieve software such as the codegenerating engine 21 at the time of startup. The program code 26 alsoincludes code defining a set of tags used in a mark up language in whichthe documents are authored as described below.

[0050] An interface 27 communicates between a databus 28 serving theprocessor 20 and memory 22 and external connection to the internet 3 forreceiving request messages and transmitting response messages.

[0051] A device identification engine 29 is provided for extracting fromreceived messages a device type identifier for identifying the remoteuser device 2 by type. The device identification engine 29 in thepresent example is implemented in software by the processor 20. In thisexample, a request message received via the internet contains aHyperText Transfer Protocol (HTTP) header which includes an ID stringdeclaring the name of the user agent which the originating device hasused when generating the request message. The name of the user agentsoftware defines for example the browser version and markup languagecapability of the device and is used by the device identification engine29 to identify the originating device using the device type identifierwhich may for example be stored as a lookup table.

[0052] The HTTP header may also yield information contained in a cookieregarding details of the user who has originated the request message.Such cookies may contain other data used for personalisation of theresponse made by the web server 1.

[0053]FIG. 2B is a further illustration of the web server 1 showingfunctional elements in a manner which illustrates the signal flow. Afront end processor 300 provides a communications interface for requestmessages received from the internet 3 and response messages transmittedto the user device 2 via the internet. The front end processor 300 sendsURL information 301 to a web application processor 302 which determinesfrom the URL the appropriate information to be included in a web pagerequested by the user. The web application processor 302 has access to adatabase 303 which may be local to the processor or may be at a remotelocation which is accessible via an appropriate communications link.

[0054] The web application processor 302 outputs a document 304comprising instructions for generating web page code. The document 304is not itself capable of being interpreted by a browser of a user deviceand therefore does not constitute “web page code” for the purpose of thepresent description.

[0055] The document 304 is input to the code generating engine 21 whichgenerates web page code with reference to content data structure 305 andthe set of policy tables 40. The output of the code generating engine isa web page code document 306 which is now in a form which is capable ofbeing interpreted by the browser of the user device 2. The web page codedocument 306 is received by the front end processor 300 and packaged asa response message transmitted via the internet 3 through the userdevice 2.

[0056] To enable the code generating engine 21 to select the appropriatedata from the content data structure 305 and to access the appropriatepolicy tables 40 ,it also requires the input of a device type identifier45 which is provided by device identification engine 29 in response toreceiving a message header signal 307 from the front end processor 300,this signal comprising information extracted from the message header ofthe request message received from the user device.

[0057]FIG. 3 illustrates schematically the policy tables 40 whichconstitute the device dependent information 25 of FIG. 2A.

[0058] In the present context, the term “policy” is used to signifyinformation to be utilised by the code generating engine 21 and whichcan be defined differently for different device types, either out ofnecessity because of different technical capabilities of differentdevice types or as a result of choice exercised by the author of thecontent code 23.

[0059] The policy tables 40 include a device policy table 30 whichcontains a number of fields relating to different technical aspects ofthe device type. By way of example, table 1 below lists a small numberof device policies that can be associated with the device type and whicheach correspond to one field (i. e. row) of the table. values areillustrated for a single device type (i. e. a single column). The devicepolicy table 30 in practice will include a large number of differentfields and values for multiple device types using a hierarchical tablestructure to represent the table in compact form. TABLE 1 Part of DevicePolicy Table POLICY VALUES Supports GIF format images true/falseSupports JPEG format images true/false Supports MP3 format audiotrue/false Supports WAV format audio true/false Can report globalposition (GPS) true/false

[0060] By accessing the device policy table 30, the code generatingengine 21 thereby is able to exercise decision making regarding choiceof code generation to suit the technical capabilities of the user device2. For example, if an image is to be included as an image file in theweb page code, it is necessary for the code generating engine 21 to haveknowledge of the form of image data compression available to the userdevice 2 from which the request message originated. The device policytable 30 includes fields indicating whether GIF or JPEG format imagescan be decompressed by the device. Similarly, audio files may becompressed in a number of different forms including MP3 format and thedevice policy table 30 also includes a field indicating whether thedevice supports MP3.

[0061] The protocol policy table 31 is responsible for mappingequivalences between device output protocols, which are generally termedmarkup languages. Examples are WML, HTML, Handheld Device MarkupLanguage (HDML) and compact HTML (cHTML). Table 2 is an example of sixof the fields in the protocol policy table 31 for a single one of thedevice types. TABLE 2 Part of Protocol Policy Table PROTOCOL ELEMENTHTML Version 4.0 <thead> HTML Version 3.2 <thead> HTML i-Mode noequivalent XHTML Basic <thead> WML Version 1.1 <thead> HDML Version 3 noequivalent

[0062] A style policy table 32 contains a number of fields whichdefine-parameters such as font family, font size, font weight and colourof headings, image borders and paragraph background as illustrated inTable 3 which shows part of the style policy table for a single one ofthe device types. The code generating engine 21 is thereby able togenerate code appropriate to the device type, in accordance with apredetermined decision which may for example reflect an agreed styleadopted as a general trading style by a particular business entity.

[0063] The way in which stylistic information is handled varies betweendifferent devices, and indeed between different device output protocols.For some, style information must be included within the generated webpage code. For others, style information must be provided in separatelygenerated code, often called a “style sheet”. TABLE 3 Part of StylePolicy Table POLICY VALUES Heading 1 font family name of a font family,e.g. Times Heading 1 font size font size, e.g. 20 Heading 1 font weightfont weight, e.g. bold Heading 1 colour colour Image border colourcolour for the border of images Paragraph background colour for thebackground colour of paragraphs

[0064] A themes policy table 33 similarly contains fields relating todecorative embellishments and logos adopted by business entities fortheir web pages and enables the author of the themes policy to tailorthe decorative features and aspects of logo such as size for each of thedevice types.

[0065] A layouts policy table 35 contains fields relating to the layoutof elements comprising text, logos, images etc at the point of renderingthe image in the user device in order to take account for example ofdifferent screen shape and size for different device types.

[0066] A dynamic policy table 36 contains fields-allowing code fordifferent device types to be tailored according to time varyingparameters. As an example, a mobile telephone having WAP facilities mayhave a bandwidth for receiving response messages which varies with timeaccording of the strength of signal available via the cellular mobiletelephone network used by the telephone to connect to the internet. Thedynamic policy may be configured to generate code requiring lowbandwidth under low bandwidth conditions and higher bandwidth underbetter conditions. The amount of image data for example may be regulatedin order to control the bandwidth required to carry the responsemessage. Simply by omitting a logo or other image, the speed with whichthe response message can be downloaded to the device can be maintainedunder poor signal strength conditions.

[0067] A component policy table 37 is also provided the purpose of whichis to determine selection of data objects as described below.

[0068]FIG. 4 illustrates schematically the manner in which the codegenerating engine 21 makes use of the data in the policy tables 40. Atstartup, the processor 20 retrieves a startup program from the storedprogram code 26 and runs the startup program to assimilate theinformation in the policy tables 40 into a series of Java objects (Javabeans) referred to herein as policy objects 41 which are then madeavailable within a run time environment 46 of the code generating engine21. The run time environment is provided by an appropriate Java VirtualMachine. The policy objects 41 each deal with specific aspects of codegeneration and contain logic and data objects configured such that eachpolicy object has knowledge of all of the relevant information availablefrom the policy tables 40 for each device type. One policy object 41 forexample may be concerned with image format capability whereas anotherpolicy object may be concerned with choice of markup language for theoutput code. The code generating engine 21 at run time processes acompiled version of a document of the content code 23, the codeconsisting of a series of instructions 42, each instruction includingone of a set of markup tags 43.

[0069] In FIG. 4, tag 43 is illustrated as being one of a number ofcustom or smart tags which, as represented schematically in FIG. 4,refers when processed to a set of classes 44 which have been written tocarry out the required function of the tags. These classes 44 in turnrefer to one or more of the policy objects 41 whenever a programdecision is to be taken which is dependent upon the device type on thebasis of data contained in the policy tables 40.

[0070] Examples of custom tags 43 provided in accordance with thepresent embodiment are summarised in tables 4 and 5. All of the tagsutilised in defining the content code 23 are device aware in the sensethat they are implemented as JSP custom tags and are associated withJava classes which access Java beans (policy objects 41) to make devicedependent decisions. The more primitive tags are referred to here assimple in-line tags as shown in Table 4. More complex tags are referredto as major block tags in Table 5. The major tags typically translateinto more than one tag in the markup language of the resulting generatedcode, for example HTML. TABLE 4 Simple In-Line Tags cite Causes text tobe displayed as a citation code Formats text suitable for illustratingcode samples em Causes text to be displayed emphasized hr Displays ahorizontal rule

[0071] TABLE 5 Major Block Tags anchor Link to another canvas, page orsection canvas Define the layout and theme to be applied to this canvash1 to h6 Define headings at 6 different levels form Define an input formtextinput (part of form) Define a text input field for a form select(part of form) Define a selection field for a form option (part of form)Define an option within a selection field for a form image Define animage logo Define a logo menu Define a menu menuitem (part of menu)Define one item within a menu shopcart A basic shopping cart tableDefine a table

[0072] The device identification engine 29 operated by processor 20extracts from a header of the received request message from a remoteuser device 2 information which identifies the device type and outputs adevice type identifier 45 which is input to the code generating engine21 to enable the set of classes 44 to extract the required informationfrom the policy objects 41.

[0073] An example of a document is given at Appendix 1 and comprises aset of instructions 42 including tags 43 to constitute the content code23 in the markup language operated upon by the code generating engine21. At line 2 for example, the tag <vt:canvas> is used in defining thetheme and layout for the web page to be created. Between the opening andclosing canvas tags (occurring at the second line and last line) is alist of components which are also implemented using custom tags 43. Thecomponents reference panes in the layout, the term “pane” being used tosignify one of a series of (generally) rectangular regions into which adisplay screen is to be divided when the web page is presented to theuser on the user device 2. A collection of panes and their relativepositions defines the layout for the page. The components can be used todefine where in the rendered page a given component's output willappear, or alternatively to determine whether or not a given componentis to be rendered when the web page is displayed for example on a userdevice having limited screen size. In this way, layouts can be used tolimit the amount of information which appears on the display screen ofcertain device types.

[0074]FIG. 5A for example illustrates a typical layout of panes 50 fordisplay on a PC and including panes which respectively include a logo, alarge colour logo, a site menu, a greeting, first, second and thirdpromotions, and a news ticker providing continuous news information.

[0075] The layout corresponding to the same content document whengenerated for display on a television screen is shown in FIG. 5B andconsists of a reduced number of panes containing respectively a largecolour logo, a greeting, a promotions menu, a site menu and a picture.

[0076]FIG. 5C illustrates the corresponding rendered screen resultingfrom code generated based on the same content document when tailored fora PDA. The number of panes is considerably reduced during codegeneration to meet the limited capabilities of the PDA and includespanes which respectively contain a medium sized black and white logo, agreeting, a promotions menu and a site menu.

[0077]FIG. 5D illustrates the layout resulting from code generationbased on the same document when tailored to a WAP telephone. Instead ofa single web page, the content is reduced to a set of fragments, oftencalled decks, each comprising a single pane accessible via a menu deck50, the set of decks further including single pane decks 51, 52 and 53for promotions 1, 2 and 3 respectively. “Deck” is a term used in the WAPstandards to indicate the units in which information is transmitted tothe wireless device.

[0078] Appendix 2 illustrates the web page code generated using thecontent code of Appendix 1 where the device type corresponds to a PChaving a browser using the HTML protocol.

[0079] Appendix 3 illustrates the corresponding code generated whenoutput to a device type corresponding to a telephone with WAPcapabilities using WML protocol. Appendix 3 contains only one deck of aset of decks contained in the generated code, the user being required toselect successive decks in order to view in turn a number of successivedisplays of the web page information. The fragmentation of the responsemessage code into decks is illustrated in FIG. 5D for example.

[0080] Appendix 4 illustrates a further deck resulting from the WML codefor the WAP telephone, this time the deck corresponding to the menu deck50 of FIG. 5D in that it contains a list of stories which can be viewedin successive decks by the user.

[0081] Appendix 5 illustrates the deck created for one of the stories.

[0082] In the above example, the code generating engine 21 is capable ofprocessing the same content code 23 to produce radically different webpage code output corresponding to different device types. The firstdevice type results in the code of Appendix 2 and the second device typewhich has lower capabilities results in the code of Appendices 3, 4 and5.

[0083] FIGS. 5E and SF illustrate the manner in which the provision ofdifferent layout definitions for two different remote user devices 2enables the entire content of a web page to be delivered to devices withdissimilar capabilities.

[0084] In FIG. 5E, the layout for a device having a large screen has theeffect of displaying the entire content in a single screen, portions ofthe content being contained in respective panes A, B, C, D, E and F.When formatted for the device with a small screen, only one of the panesA, B, C, D, E and F is displayed at any given time, the content therebybeing fragmented into fragments A, B. C, D, E and F as illustrated inFIG. 5F. Fragment A is designated as a root fragment via which theremaining fragments may be accessed using a menu.

[0085] For the device with small screen capability, the fragment mayneed to be re-shaped or the content presented differently so that it mayfor example be necessary for the user to scroll through text to see theentire contents of a given fragment containing text.

[0086] A multi-menu structure may alternatively be utilised asillustrated in FIGS. 5G and 5H. Instead of defining the layout in termsof panes, the layout is defined in terms of a series of segmentsdefining areas of the display and designated as either control segmentsor content segments. In FIG. 5G, a control segment 55 contains a menubar 56 composes of a series of icons which can be user selected.

[0087] A content segment 57 defines a further area of the display anditself contains a further content segment 58. Content segment 57 alsocontains a further control segment 59 which contains a second menu bar510.

[0088] In this example, selection using the first menu bar 56 calls fordisplay within control segment 59 of a selected one of a set of secondmenu bars 510 as illustrated in FIG. 5H. Each of the second menu bars510 allows selection from a respective set of content items 511.

[0089] The example of FIGS. 5G and 5H illustrates an alternative methodof page description in which a montage tag defines page layout in termsof a series of segments which may be content segments or controlsegments. As shown in this example, it is possible for a content segmentto contain further segments including both control and content segments.

[0090]FIG. 5G corresponds to the web page viewed on a large screendevice. When translated to a small screen device, the user might forexample see only one segment at any time, initially viewing the firstcontrol segment 55 to allow selection of one of the second menu bars510, and subsequent selection of one of the content items 511.

[0091] The resulting layout of FIG. 5G can be implemented using theinline frames feature of HTML.

[0092] The above examples of FIGS. 5A to 5H take two extremes of displaycapabilities of user devices. For devices of intermediate capabilities,alternative layouts showing perhaps two or three segments or panes maybe appropriate. It may also be appropriate to modify the content withineach pane or segment according to the capabilities of the device. Forexample, a PC is generally capable of a higher standard of imagepresentation including colour and moving images whereas a WAP phone maynot have colour facility and may have limited screen resolution andrefresh rate. This requires that for each pane or segment the contentmust be stored in a number of different forms appropriate to differentdevices.

[0093] The policy tables 40 are each arranged to have a hierarchicalstructure such as the structure illustrated for example in FIG. 6 whichshows the hierarchy of the device policy table 30. Characteristics of anotional root device type define an upper level 61 of the hierarchy.This root type may be regarded as representing default values for thedevice policy table 30. A second layer 62 defines device types whichdiffer from the root device type in a number of features. The devicepolicy table will therefore include entries (columns) for those fieldsin which the parameters describing the root device type are notinherited. The third layer 63 of the hierarchy includes sub-divisions ofthe general device types of the first layer, for example a number ofdifferent PDA device types are illustrated. Each of these device typeswill inherit many of the parameters describing the capabilities of thePDA in the first layer but will differ in a number of respects, therebyrequiring entries in respective columns of the device policy table forthose fields which contain parameters not inherited.

[0094] Subsequent layers 64 and 65 of the hierarchy define furthersub-divisions of device type.

[0095] The device identifier 45 will identify a node in thishierarchical tree and the complete set of attributes relevant to thedevice type may then be acquired by traversing the tree defined by thehierarchy structure from the node through successive layers to the rootdevice type defined in the upper layer 61, acquiring further inheritedattributes at each layer.

[0096] An advantage of organising each of the policy tables 40 in such ahierarchical structure is that, when it is required to expand the policytables 40 to include data for an additional device type, this can beachieved by inserting a new node to the hierarchical tree structure andconnecting the new node with a branch from a parent node in an adjacentupper layer. The parent node is selected to be the node from which thedevice type inherits the most complete set of attributes.

[0097] If for example a mobile telephone is already represented in thepolicy tables 40 and a new model of the mobile telephone becomesavailable, any change in the capabilities of the new model which requirechanges to policy can be represented by a minimal amount of data,corresponding to a new entry in each policy table containing values onlyin those fields for which attributes are not inherited from the existingmodel of mobile telephone represented by an existing node in thehierarchy.

[0098] Information for updating the policy tables 40 to includeadditional device types may be provided by the service centre 5 shown inFIG. 1 and transmitted to the web server 1 for example over the internet3. The device dependent information 25 including the policy tables 40may then be updated by operation of data manager 190, a software moduleof the web server 1 represented schematically in FIG. 2. Generally thisprocedure may be undertaken during normal operation of the web server 1and operation of the code generating engine 21. In response to thepolicy tables 40 being updated, the policy objects 41 automaticallyupdate themselves while managing their current use in the operatingenvironment 46 of the code generating engine 21. This activity isregulated so as not to disrupt any web page code currently beinggenerated by the code generating engine 21.

[0099]FIG. 7 illustrates an example of software provided to the webserver in a preferred embodiment. The software includes the set ofpolicy tables 40 and a set of tags 70, including both tag definitionswhich provide the necessary information to enable authoring of contentand code for implementing the tags i.e. the program code which runs wheneach tag is used in the operating environment of the code generatingengine 21.

[0100] The code generating engine 21 and device identification engine 29are among the items provided to the web server. Also provided is areporting engine, 71. The reporting engine is operated by the processor20 to perform tasks such as measuring usage of the web site. Thisinformation may be used to demonstrate, for example, for the purpose ofadvertising, the extent to which the is used and also to enablepersonalised marketing to be targeted to users of the site. As anexample, a database of users may be utilised to tailor a response to arequest message from a particular user such that a response messageincludes an additional page containing a special offer on a productregistered as being of interest to a particular user.

[0101] The software further includes an integration engine 72 forcommunicating with routine activities such as invoicing and purchaseordering that can arise in response to use of the website by users ofthe remote user devices 2.

[0102] The software further includes an operations manager 73 formanaging the overall system to control operation, to allow errors to bedetected and to allow resources to be controlled accordingly.

[0103] Also provided is a program 74 for the creation of the policyobjects at startup as described above with reference to FIG. 4.

[0104] The device identification engine 29 is also provided, asdescribed above.

[0105] Also, a web application 75 processes the received URL request toidentify the requested web page and select the appropriate document ofcontent code 23 for import to the code generating engine 21.

[0106]FIG. 8 illustrates schematically a typical hardware required forimplementing the present invention in a small to moderate sized webserver. A personal computer 80 having facilities for receiving programssuch as those summarised in FIG. 7 from a portable storage medium 81 isconnected via a firewall 82 to a router 83. The router 83 is connectedvia a high bandwidth leased line 84 to an internet service provider 85for connection with the internet 3.

[0107] Programs and data required for operating the web server 1 may becommunicated from the service centre 5 in the form of the portablestorage medium 81 or alternatively as signals 86 communicated via anetwork such as the internet 3.

[0108] As illustrated schematically in FIG. 9, the above described webserver and software configuration allows content code 23 to be storedseparately from presentation information 90 so that, when a requestmessage 91 is received by the system, the code generating engine 21 isable to generate dynamically a response message 92 containing newlygenerated web page code representing the combination of content code andpresentation information. A particular advantage of this arrangement isthat it is relatively easy to alter presentation information such asstyle, and themes including logos for example, simply by updating thepresentation information 90. Major re-engineering of the authored codeis thereby avoided. Separate storage may involve location in separatefiles on the same hard disk or in physically separate memory devices.

[0109] To update the presentation information 90, it may simply benecessary to change data contained in the style policy table 32, thethemes policy table 33 or the layouts policy table 35.

[0110]FIG. 10 illustrates schematically a preferred embodiment in whichthe web server 1 is adapted to operate in a business environment for amedium to large scale business. The web server 1 comprises a productionserver 100 responsible for the production of web page information inresponse to request messages from remote user devices 2 and theoutputting of response messages comprising the web page code. As such,the production server 100 performs the functions described above asbeing performed by the web server 1 of preceding figures. Here the webserver 1 also comprises a development server 101 which is responsiblefor interaction between the web server and the service centre 5 and forperiodically updating the production server 100 with new software.

[0111] Each of the production server 100 and development server 101comprises a respective processor cluster with substantially greatercomputing power than the personal computer 80 described above.

[0112] The development server 101 may be regarded as a series ofprocessors performing development and staging processes enabling severallevels of tests to be applied to new software before downloading the newsoftware to the production server 100.

[0113] It is necessary for the software operated by the productionserver 100 to be updated periodically to take account of the evolutionof new types of remote user device 2 and also to incorporate new contentto be delivered as web pages.

[0114] As represented in FIG. 10, the service centre 5 maintains acentral reference database 102 from which data such as updated policytables is periodically communicated to the development server 101. Thiscommunication of data occurs using the Internet 3, an XML syntax beingused to structure data transmitted using HTTP protocol. As illustratedin FIG. 10, the development server 101 periodically requests an updateof the policy tables 40 by outputting a request message 103 and receivesthe requested data in a response message 104.

[0115] The development server 101 on receiving a response message 104 isused to conduct tests on the new data and may be used to make localadjustments for example to add appropriate new layouts.

[0116] After testing and modification, new policy tables arecommunicated from the development server 101 to the production server100 via appropriate firewalls.

[0117] When updating databases in the production and development serversit is not generally necessary to transmit the entire contents of thedatabase, instead relying upon editing commands constituting thetransmitted data in HTTP protocol accompanied by metadata in the XMLsyntax.

[0118] Also illustrated in FIG. 10 is a probe site 105, the function ofwhich will be described below, and which represents a server accessiblevia the Internet 3 and having a URL. The physical location of the probesite 105 is shown in the present example to be separate from thelocation of the web server 1.

[0119]FIG. 11 illustrates schematically the manner in which theproduction server 100, probe site 105 and service centre 5 interact inresponse to an encounter for the first time with a remote user device 2of a new type. The new type of device 2 may for example be the latestversion of a mobile telephone using WAP and including features which areupgraded with respect to those of previous models by a givenmanufacturer, having for example different display capabilities such asan increased size and the ability to display colour images.

[0120] The user of the new device 2 wishing to access the web siteprovided by the web server 1 actuates browser software within the deviceto generate a request message 110 which is output via the Internet 3 tothe URL of the production server 100.

[0121] The production server 100 receives the request message 110 andinputs the message to the device identification engine 29 shown in FIG.2 in an attempt to extract a device type identifier from the ID stringcontained in the HTTP header of the request message. The deviceidentification engine 29 however determines that the request message 110contains an unknown identification stream. The production server 100however needs a device type identifier to enable the appropriate policytables to be accessed, the device ID 45 being an essential input to thecode generating engine 21 as illustrated in FIG. 4.

[0122] The production server 100 responds to this determination by thedevice identification engine 29 by generating a redirect message 111which is transmitted to the new device 2 and causes the device toredirect the request message 110 to the URL of the probe site 105. Inconsequence, a new request message 112 is output by the device 2 andtransmitted to the probe site 105.

[0123] The probe site 105 analyses the identification string containedin the request message 112 and is able to extract some basic informationas to the communication protocols and capabilities of the device 2. Thislimited information is sufficient to enable the probe site 105 togenerate a probe 113 in the form of an agent which can be processed bythe browser of the device 2 and constitutes software which can be run bythe processor of the device.

[0124] The probe 113 is transmitted to the device 2 in a further message114 and on receiving this message the browser of the device displays astandard response web page to the user while processing the probe inbackground.

[0125] The probe 113 causes the device 2 to generate a further requestmessage 115 which is addressed to the probe site 105 and which containsmore detailed information of the capabilities and protocols associatedwith the device 2, in accordance with the information requested by theprobe.

[0126] The probe site 105 responds with a further redirect message 116which is transmitted to the device 2 and instructs the device toredirect the request message 110 to the production server 100. Thedevice 2 follows this redirection and outputs a further request message117.

[0127] At the same time as outputting the redirect message 116, theprobe site 105 sends a notification message 118 to the service centre 5to inform the service centre of the existence of the new device 2 and topass on the information retrieved in message 115 by the use of the probe113.

[0128] The service centre 5 stores the received information for lateruse and processes the information to generate a temporary update message119 which is transmitted to the production server 100 and contains adevice identifier to enable the code generating engine 21 to generatethe web page code as requested by the user of the device 2. The web pagecode is then transmitted to the user in a final response message 120.

[0129] The temporary update message 119 generated by the service centre5 provides the production server 100 with the nearest appropriateexisting device type identifier. Consequently, the web page codegenerated may not be perfectly suited to the new device 2 but willgenerally be capable of being interpreted and displayed by the device,for example using -default settings of the browser.

[0130] The service centre 5 is then required to update the centralreference database 102 with appropriate information including revisedpolicy tables. This information may then be included in the next updatecommunicated to the development server 101 for ultimately being used toupdate the database of the production server 100.

[0131] In this way, the above system is capable of continually reactingand adjusting to the evolution of new devices accessing web sites viathe Internet, without necessarily being provided with advance notice bythe manufacturers of the new devices or the direct provision by them ofdetailed technical data. Optionally, the service centre 5 may requestsuch data by contacting the manufacturer, but this need not beobligatory to obtain satisfactory operation.

[0132]FIG. 12 illustrates an embodiment in which the web. server 1 isprovided with a cache memory 120. A gateway server 121 acts as a gatewayinterfacing with the internet 3 to receive request messages from remoteuser devices 2 and to respond by sending the requested web page code 122either by requesting the dynamic generation of the web page code from adynamic word page server 123 or, if the requested web page code alreadyexists as a static web page in the cache memory 120, retrieving the webpage code from cache memory.

[0133] The dynamic web page server 123 functions to dynamically generatethe web page code in the manner described above using the device typeidentifier 45 extracted from the received URL request and the storedcontent code 23 corresponding to the URL.

[0134]FIG. 13 illustrates schematically the steps carried out by theprocessor of the gateway server 121. At step 130, the gateway serverreceives the URL request and extracts the device type ID 45 andidentifies the document of the content code 23 which contains theinstructions necessary for generating the required web page code.

[0135] At step 131, the gateway server 121 queries whether the web pagecode already exists as a static web page in the cache memory 120 forthis device type ID and URL and, if available, retrieves at step 132 theweb page code.

[0136] If not available from cache memory 120, the gateway server 121requests at step 133 from the dynamic web page server 123 the generationof the web page code and transmits the device type ID and URL details.

[0137] Accordingly, at step 134 the gateway server 121 receives thenewly generated web page code.

[0138] At step 135, the gateway server 121 outputs the web page code tothe remote user device 2 via the internet 3.

[0139]FIG. 14 illustrates schematically the steps performed under thecontrol of the processor of the dynamic web page server. At step 140,the dynamic web page server receives the request for generation of theweb page code and also receives the device type identifier informationand information derived from the URL required to identify the documentof content code 23. The required content code 23 is retrieved frommemory and is processed in the run time environment 46 of the codegenerating engine 21 to produce the required web page code at step 142.

[0140] At step 143, the dynamic web page server 123 determines from thecontent code 23 whether the resulting web page code is flagged as beingsuitable for being stored in cache memory 120 and, if so, determinesfrom the content code the period for which the cache memory version isto remain valid. This information at step 144 is used to create metadatawhich is added to the file containing the web page code and which atstep 145 is output to the cache memory 120 to be stored for the validityperiod.

[0141] At step 146, the dynamic web page server 123 outputs the web pagecode to the gateway server 121 to be received at step 134 as describedabove.

[0142] When authoring the content code 23, the author therefore has theoption of adding extra attributes to canvas tags to define whether ornot the resulting page can be cached and how long it can remain valid incache memory. The cache memory 120 writes new cached pages into memoryin the manner which overrides any stored pages for which the validityhas expired.

[0143] In FIG. 12, a set of pages of content code 23 is representedschematically together with respective cache memory control data 124 foreach page, the control data being set by the author of the page todetermine the above instructions for caching in memory 120.

[0144] The generation of code by the code generating engine 21 has beendescribed above with reference for example to appendix 1 which showsinstructions used for creating content code 23 for generating an exampleweb page. Typically, as in this example, the execution of the contentcode 23 by the code generating engine 21 will require content to beretrieved from date storage. Data objects such as image files aretherefore imported for inclusion in the web page code which is to beoutput by the code generating engine 21.

[0145] The author of the web page may author a component to refer byname to a data object to be imported. Different versions of the dataobject are stored in a data structure which is hierarchical and suchthat different hierarchical levels correspond to different capabilitiesof remote user devices 2. The author of the content code 23 may definefor each object the appropriate version to be utilised for each devicetype ID 45 by entering data in a in component policy table 37 asillustrated in FIG. 3. The component policy table may then follow thehierarchy of FIG. 6A to enable the data object version to be defined foreach possible device type ID. This approach is referred to hereafter asdefining data objects in terms of targeted content since it is theauthor of the code which targets the particular version of the dataobject to be used for each remote user device 2.

[0146] Alternatively, a number of versions of data object may beprovided in a hierarchy with characteristics of each version of the dataobject being described in associated metadata for each version.Automatic selection of the appropriate version may then be made using acomponent logic software module 150 as illustrated schematically in FIG.15.

[0147] The component logic software module 150 selects the appropriateversion on the basis of the data object metadata, layout considerationsdefined by the layout policy table 35 and information about the deviceprovided by the device policy table 30. This approach to selection ofthe data object version will be referred to below as untargeted contentselection.

[0148] The code generating engine 21 may operate using either one oftargeted content or untargeted content selection. Alternatively andpreferably, the code generating engine 21 is capable of selectivelymaking use of both targeted content and untargeted content selection,thereby providing the author with the freedom when authoring the contentcode 23 to either define data object versions or leave selection to beautomatically processed using the component logic software module 150.

[0149]FIG. 16 illustrates schematically the manner in which bothtargeted and untargeted content may be utilised. At step 160, contentcode 23 is input to the code generating engine 21 together with thedevice type ID 45 and at step 161 the processing of the code is started.

[0150] At each instance of a component of the content code 23 requiringa data object to be imported, the code generating engine 21 attempts atstep 162 to import an author defined version of the data object. If itis determined at step 163 that such an author defined version exists andit is successfully imported, processing continues, determining at step164 whether any further data objects remain to be imported.

[0151] If however at step 163 it is not possible to successfully importany author defined version, processing continues with step 165 whichrequires operation of the component logic software module to identifythe appropriate object version. At step 165 the selected data objectversion is then imported and the code generating process continues. Whenit is determined at step 164 that no further data objects are to beimported, the remaining processing to generate the web page code iscompleted at step 167 and at step 168 the completed web page code isoutput.

[0152]FIG. 17 illustrates schematically the manner in which data objectsstored in the database 19 are stored in a hierarchical data structure toallow the component logic software module 150 to automatically selectthe appropriate data object version.

[0153] If for example the author designs a web page in which a videoclip is to be displayed at a defined area of the screen of a user devicein the form of a personal computer, the video clip is stored in thedatabase 19 as a video data object 170 and an associated component name171 is devised to enable the code generating engine 21 to reference thevideo data object 170 by name. The video data object 170 ischaracterised by metadata 172 stored in association with the data objectand contains data fields sufficient for the component logic softwaremodule 150 to make a determination as to whether a given user device 2as defined by device type identifier 45 is capable of receiving anddisplaying the video clip from the data object.

[0154] The author may also store, as shown in FIG. 17, differentversions of the video data object suitable for use by different devicetypes, each accompanied by respective metadata.

[0155] The author also stores in the database a photographic image dataobject 173 with associated metadata 174. Similarly, the author may storea set of related photographic image data objects 173 having attributesappropriate to different device types and accompanied by respectivemetadata. If the component logic software module 150 determines from themetadata 172 that none of the video data objects can be displayed by auser device for which the web page code is currently being prepared, thephotographic image represents a fall back position enabling a staticphotographic image to be rendered in place of the video clip. Thephotographic image will therefore generally display related subjectmatter and may for example comprise a still taken from the video clip.

[0156] The author may also enter into the database a graphic image dataobject 175 with associated metadata 176. Similarly, the author may entera set of related graphic image data objects with respective metadata,suited to different device types. The graphic image constitutes afurther fall back position for use if an appropriate version ofphotographic image is not available.

[0157] The author may also enter additional fall back positions such assimple text objects 177 with associated metadata 178. The text dataobject 177 represents a final fall back for situations where-thecomponent logic software module 150 determines that even the graphicimage 175 cannot be rendered by the user device 2.

[0158] The data objects 170, 173, 175 and 177 are stored in the database19 in a hierarchical data structure as illustrated schematically in FIG.17 in which different levels of the hierarchy correspond to levels ofuser device capability. The text data object 177 is in this example aroot level of the hierarchy representing the lowest level of capabilityof the user device 2 and therefore representing the ultimate fall backposition.

[0159] If for example the user device 2 is identified by device typeidentifier 45 as being a personal computer, the component logic softwaremodule 150 will select data object 170. If the user device 2 isidentified as being a pocket PC without the ability to render videoclips, but having the ability to render photographic images, thecomponent logic software module 150 will select data object 173. If theuser device 2 is identified as being a mobile telephone with WAPfacilities, the module 150 will select the graphic image data object175. If however the user device 2 is identified as being a conventionalmobile telephone without WAP facilities then text data object 177 willbe selected.

[0160] The hierarchical data structure applies to other types of dataobject to enable appropriate data objects to be selected, as for examplein the case of the web page code defining a link of some sort. The linkmay comprise an HTML link, a WML link, an email link or simply atelephone number for autodialled connection in the case of the userdevice 2 being a mobile telephone.

[0161] A further example of data objects which can be accessed using thesame component name is that of script components such as JavaScript andWML Script where the same content may be written in the appropriatescript for use in different devices. The author may therefore write dataobjects in the variety of required script languages for storage in thehierarchical structure of FIG. 17 and retrieval in response to componentname. As in the previous examples, selection may be made on the basis ofthe metadata accompanying each data object on the basis of thecapabilities of the remote user device 2, as determined by using thedevice ID 45 with reference to the device policy table.

[0162] The use of the above hierarchical data structures provides anefficient method of asset management for the system where the assetscomprise the collection of data objects which are capable of beingdelivered in web page code form by the system.

[0163]FIG. 18 illustrates the manner in which data in the form of textmay be stored in a hierarchical data structure to enable differentversions of the text to be retrieved to suit the capabilities of theuser device 2 and the preferences of the user. The full text in Englishof a document object is stored in box GB TEXT 1, suitable for examplefor display on the screen of a PC. A reduced version of the text whichhas been edited by the author is stored as data object GB TEXT 2,suitable for display on a palm held computer of reduced screen size. Asmaller still version of edited text is stored in data object GB TEXT 3,suitable for display in a hand held device of limited memory and finallyGB TEXT 4 contains a minimal text version for display in a mobiletelephone.

[0164] Each of these text versions are in the English language.Corresponding text objects in the French language are contained in FRTEXT 1, FR TEXT 2, FR TEXT 3 and FR TEXT 4. Similarly, data objectscontaining text in the German language are contained in DE TEXT 1, DETEXT 2, DE TEXT 3 and DE TEXT 4.

[0165] The data objects are addressed by component name 171 and alanguage identifier 180 which in this example indicates whether theEnglish, French or German text version is required.

[0166] The language identifier is input to the code generating engine inaddition to the device ID 45 and typically is extracted from the body ofthe request message generated by the browser of the remote user device 2in response to input of a user preference by the user. Each of the textdata objects such as GB TEXT 1 has associated metadata 181 indicatingthe relevant parameters of the object, including in particular the sizeof code representing the text. A decision may thereby be made on thebasis of the size of the code indicated by the metadata 181 as towhether a given object is appropriate for retrieval for a given remoteuser terminal. The optimum data object may thereby be selected bytraversing the hierarchical tree structure of FIG. 18 until theappropriate data object is located.

[0167]FIG. 19 illustrates a further embodiment in which a pane dissector190 is provided to modify the output produced by the code generatingengine 21. Such an arrangement is advantageous in preventing thetransmission of a response message containing an amount of code which isgreater than the available memory capacity of the remote user device 2.For small memory devices such as mobile telephones, overloading theavailable capacity can cause the microprocessor of the device to crashor enter a lock situation. Although the author of the content to beprovided in response to queries from such devices may take note of thelimited memory capacity of the device, it is in practice difficult topredict with certainty the actual amount of code which will be outputfrom the code generating engine 21 so that a solution is to additionallyplace a device such as the pane dissector 190 downstream of the codegenerating engine 21 to trap the outgoing code and measure the codeamount.

[0168] If the code amount exceeds the indicated available data capacityof the user device 2, the dissector 190 is arranged to automaticallydivide or dissect the document into a number of fragments, referred toherein as shards.

[0169] As illustrated in FIG. 19, the pane dissector 190 receives thedevice type identifier 45 from the device identification engine 29 andaddresses the device policy table in order to determine from the devicetype identifier the available memory capacity of the user device 2.

[0170] If division of the pane is appropriate, a first one of theresulting shards is output by front end processor 190 and the remainingshards are stored in a buffer memory 191. The front end processor 190may then respond to subsequent requests from the user device 2 bysupplying in turn the remaining shards in respective response messages.

[0171]FIG. 20 illustrates schematically the process of dissecting apane, the term pane in this context being used to indicate a web pageintended to be transmitted to a remote user device 2.

[0172] At step 200, the code representing the pane is generated by thecode generating engine 21, based on the device type identifier 45 andthe nature of the request message received via the internet 3.

[0173] At step 201, the code output from the code generating engine 21is received and measured by the pane dissector 190 and at step 202 thepane dissector accesses the device policy table to look up the datacapacity of the remote user device 2.

[0174] At step 203, the pane dissector 190 determines whether or not theamount of code is equal to or less than the data capacity of the remoteuser terminal 2 and, if so, at step 204 outputs the code withoutperforming any dissecting step.

[0175] If however the amount of code is greater than the available datacapacity, the dissector at step 205 dissects the code into a number ofshards, each shard having an amount of code less than the available datacapacity. At step 206 the shards of the divided pane are stored inbuffer memory 191. At step 207 one of the shards is output to the serverfor inclusion in a response message to the remote user device 2.

[0176]FIG. 21 illustrates a pane 210 from which regions A, B, C, D, Eand F are dissected to form shards 211 to 216, each of which isseparately stored in the buffer memory 191 and may be transmitted inseparate response messages to the remote user device 2.

[0177]FIG. 22 illustrates the additional use of a memory referred tobelow as a user session memory 220 for storing information defining auser session under circumstances where the messages between the serverand user device 2 are fragmented to take account of the limited datacapacity of the user device.

[0178] A typical example of when such an arrangement is appropriate iswhen a form filling exercise is to be completed in a user session. Forhigh capacity devices such as personal computers, it is commonplace fora form to be provided in a single screen to the user and for the form tocontain multiple fields for completion by the user.

[0179] For example, in FIG. 23 form 230 defines multiple data fields231. For a device 2 of limited capacity, it may be necessary to fragmentthe form into a number of fragments 232 to 237 which containrespectively portions A, B, C, D, E and F of the form 230.

[0180] During a user session, the form 230 is dissected into thefragments 232 to 237 and the corresponding code for each fragment storedin buffer 191. Initially only fragment 232 is transmitted to the userdevice 2 and the user responds with a response message which isprocessed by the server 1. The response corresponding to data fieldscontained in region A of the form are stored in the user session memory220. The next fragment 233 is transmitted to the user device and thecorresponding response stored in the user session memory. This processis repeated until the final fragment 237 is transmitted. The response tothis fragment F of the form includes actuation of a submit button 238.If actuation of the submit button 238 is contained in the final responsemessage, the information required in the user session memory 220 iscomplete and the complete set of data from the form filling exercise ispassed to a data processing application 239.

[0181] The manner in which the form is divided into regions A, B, C, D,E and F is defined by the author as part of the layout policy.

[0182] The code transmitted to the user device 2 typically also includesscript defining instructions for operating the browser of the remoteuser device 2 to perform validation and verification of data entered bythe user during form filling. The script is generated by the codegenerating engine 21 based on the tags written by the author whoincludes a definition of validation rules to be applied to the dataentered by the user during form filling.

[0183] If for example a data field is indicated as being a numericalfield, numerical value limits may be applied for validation purposes.

[0184] The manner in which the script code is generated by the codegenerating engine 21 depends upon the version of script languageappropriate to the remote user device 2, as indicated by the protocolpolicy.

[0185] In a further example, a user device 2 is of a type with limitingprocessing power such as a mobile telephone in which validation rulesare applied by software existing in the processor or SIM card of thedevice. In this instance, the code generating engine 21 is not requiredto generate script for transmission to the device to perform thevalidation steps since it is sufficient to provide validation parametersin a format dictated by the-existing software within the user device.

[0186] When responding to a remote user-device 2 which uses a protocolsupporting style sheets, the author may specify that a style sheet is tobe generated by the code generating engine 21. The style sheet may beshared across multiple pages. For those devices where the availableprotocol does not support style sheets, additional code is generated bythe code generating engine 21 to create a visual effect in the resultingdisplayed pages which emulates the style sheet definition defined by theauthor.

[0187] For example, HTML 4 browsers can apply style sheets to receivedHTML whereas HTML 3 browsers cannot. It is therefore necessary for HTML3 browsers to receive additional HTML code adding font, colour and otherattributes in order to achieve the same effect as provided by the stylesheet.

[0188] The author is required to define the style sheet information andthe code generating engine 21 will, if necessary, automatically generatethe additional code required if style sheets are not supported.

[0189] Some user devices do not provide visual display, as for examplethose devices designed for use by visually impaired users. Such devicesare typically served by a service provider which hosts a voice browseron a computer of the service provider, thereby converting HTTP receivedcode into communications signals delivering voice messages. Such aservice provider could therefore act as an intermediary between theserver 1 and the remote user device 2 of the above embodiments. Theoutput web page code could then advantageously be output by the codegenerating engine in voice XML.

[0190]FIG. 24 illustrates one of the functions of the graphical userinterface 4 utilised when storing files created during web pageauthoring. A common situation arises where the same background image andtext are to be incorporated into web pages downloaded to a number ofdifferent device types requiring different formats. A data converter 241is provided in accordance with a further embodiment of the presentinvention to assist the author in the task of generating appropriatefiles. As shown in FIG. 24, an authoring suite 240 is provided with adata converter 241 for converting a data file output by the authoringsuite into a set of files which are stored by action of a file manager242 in the data structure.

[0191]FIG. 25 illustrates the steps in the method of operating theelements of FIG. 24. At step 250, the data converter 241 receives fromthe authoring suite 240 a file containing data which is to be stored asa data object. As an example, this data file comprises an image in GIFformat.

[0192] At step 251, the data converter 241 determines the type of data(i.e. whether image, text or other data type) and refers to the devicepolicy table 30 to determine a list of different data formats which maybe required during operation of the code generating engine 21, accordingto the value of the device type identifier 45.

[0193] At step 253, the data converter 241 generates for each of theseformats in the list a converted file having the appropriate format andassociated metadata. At step 243, the file manager 242 stores the filesin the data structure.

[0194] This arrangement enables the author to enter text and graphicparameters only once, the data converter and file manager thenundertaking the task of generating sets of files in different formatsfor storage and subsequent use as data objects.

[0195] The above described embodiments have referred to implementationusing JAVA, by way of example. Alternatives to JAVA may be used inimplementing the present invention and the references to JAVA, JAVAbeans and JAVA virtual machine are not to be read as limiting the scopeof the invention.

[0196] The present invention can be implemented by a computer programoperated on a computer in the context of a web server. An aspect of thepresent invention thus provides a storage medium storing processorimplementable instructions for controlling a processor to carry out themethod as hereinbefore described.

[0197] Further the computer program can be obtained in electronic formfor example by downloading the code over a network such as the internet.In accordance with another aspect of the present invention there isprovided an electrical signal carrying processor implementableinstructions for controlling a processor to carry out the method ashereinbefore described.

[0198] The present invention has applications to networks other than theinternet including private networks and further public networks.

[0199] The policy tables, custom tags and the code generating engine maybe supplied as software products either separately or in combination asa software kit and constitute further aspect of the present invention,whether embodied in storage medium or electrical signal form.

[0200] The device names referred to in FIG. 6 include in layers 63, 64and 65 the names of device types which are hereby acknowledged as beingTrade Marks.

[0201] Appendix 1—Canvas Authored for the Volantis Product <%@ includefile=“Volantis.jsp” %> <vt:canvas layoutName=“eportal” themeName =″theme1> <vt:anchor href=“TestPortal.jsp” pane=“logo1” image=“stars”/><vt:logo pane=“logo2” src=“volantis” alt=“volantis”/> <vt:welcomepane=“welcome”/> <vt:h2 pane=“shop”>Shop for Cool Stuff at <ahref=“shopcart.jsp.”>Shop Volantis</a></vt:h2> <vt:Headlinepane=“headlines” show=“2” /> <vt:Content pane=“cpynews”/> </vt:canvas>

[0202] Appendix 2—Resulting Page Sent to a Personal Computer Using HTML<html> <head> <link REL=STYLESHEET HREF=“css/JSP-Styles.css”TYPE=“text/css”> <script language=“JavaScript”> <!-- //--></script></head> <body> <table border=0 cellpadding=0 columns=2><tr> <tdalign=center valign=top> <table border=0 cellpadding=0 columns=1><tr><td align=center valign=top> <table border=0 cellpadding=0columns=1> <tr><td align=center valign=top> <table border=0cellpadding=0 columns=2><tr> <td align=center valign=top> <tableborder=0 cellpadding=0><tr> <td> <a href=“TestPortal.jsp” > <imgsrc=“images/stars0.jpg”/> </a> </td></tr></table> </td/22 <tdalign=center valign=top> <table border=0 cellpadding=0><tr> <td> <imgsrc=“images/volantis0.jpg” alt=“volantis”> </td></tr></table> </td></tr></table> </td></tr> <tr><td align=center valign=top> <tableborder=0 cellpadding=0><tr> <td> <hr><b>Welcome to Volantis; RhysLewis</b> You can set up your news preferences <ahref=e_setupnewsdevice.adp>here</a> <br><hr> </td></tr></table></td></tr> <tr><td align=center valign=top> <table border=0cellpadding=0><tr> <td> <h2>Shop for Cool Stuff at <ahref=“shopcart.jsp”>Shop Volantis</a></h2> </td></tr></table> </td></tr></table </td></tr> <tr><td align=center valign=top> <table border=0cellpadding=0 columns=2><tr> <td align=center valign=top> <tableborder=0 cellpadding=0><tr> <td> <table align=right border=0><tr><td><table borderwidth=1 bordercolor=cyan><tr><th class=headlinealign=left>XML and metadata news</th></tr> <tr><td><ahref=clickthru.jsp?cat=278&url=http://c.moreover.com/click/here.pl?x8102028>ThinkersGroup.com Completes Beta Test of Web-To-WirelessApplication</a></td></tr> <tr><td class=sub>07 Jul 200008:05AM</td></tr> <tr><td><ahref=clickthru.jsp?cat=278&url=http://c.moreover.com/click/here.pl?x8099873>XSLgives your XML some style</a></td></tr> <tr><td class=sub>07 Jul 200006:59AM</td></tr> </table></td></tr> <tr><td><table borderwidth=1bordercolor=cyan><tr><th class=headline align=left>Wireless sectornews</th></tr> <tr><td><ahref=clickthru.jsp?cat=277&url=http://c.moreover.com/click/here.pl?x8102312>Nokia,C&W team up to offer mobile internet services</a></td></tr> <tr><tdclass=sub>07 Jul 2000 08:16AM</td></tr> <tr><td><ahref=clickthru.jsp?cat=277&url=http://c.moreover.com/click/here.pl?x8102269>NASDAQOutlook; Qualcomm To Finish Physics Lesson Soon, Then CouldDouble</a></td></tr> <tr><td class=sub>07 Jul 2000 08:15AM</td></tr></table></td></tr> <tr><td><table borderwidth=1 bordercolor=cyan><tr><thclass=headline align=left>Top technology stories</th></tr> <tr><td><ahref=clickthru.jsp?cat=273&url=http://c.moreover.com/click/here.pl?x8102034>PRIMUSTelecommunications and Inktomi Forge Strategic Alliance To Build GlobalInfrastructure for Streaming Media</a></td></tr> <tr><td class=sub>07Jul 2000 08:05AM</td></tr> <tr><td><ahref=clickthru.jsp?cat=273&url=http://c.moreover.com/click/here.pl?x8098274>JesseBerst’s Anchordesk: The Long Wait for Web Phones</a></td></tr> <tr><tdclass=sub>07 Jul 2000 06:19AM</td></tr> </table </td></tr></table> </td><td align=center valign=top> <table border=0 cellpadding=0><tr> <td><table width=100% align=top> <tr><td colspan=2><h2>Informix UpgradesJava Database</h2></td></tr> <tr><td width=30% valign=topalign=left><img src=database.gif border=0></td> <tdwidth=70%><p><b>Informix</b> (NASDAQ: IFMX) says it has upgraded itsCloudscape Java-based database to support Windows CE and Pocket PC. Inaddition to adding platforms, Cloudscape 3.5 has added greatersecurity.</p>

[0203] <p>Cloudscape 3.5 consists of the Cloudscape database managementsystem, Cloudsync for data and application synchronization andCloudconnector, a server framework for Internet connections to theCloudscape DBMS. </p>

[0204] <p>The company is demonstrating the update at the JavaOneconference this week in San Francisco. It will be commercially availablein July 2000. Server pricing starts at $1,999. </p> </td></tr>

[0205] <tr><td colspan=2><h2>AT&T Wireless, Nortel to TrialGPRS</h2></td></tr>

[0206] <tr><td width=30% valign=top align=left><img src=wireless.gifborder=0></td>

[0207] <td width=70%><p>AT&T Wireless Services (NYSE: AWE) and NortelNetworks (NYSE/TSE: NT) say they will start testing broader-band GeneralPacket Radio Service (GPRS) in the U.S. this summer and are workingtoward the eventual delivery of faster third-generation (3G) service.</p>

[0208] <p>The GPRS tests will begin in several unnamed major U.S. citiesthis summer, the companies said in an announcement. The companies areworking together to eventually introduce full 3G TDMA-EDGE technology.</p>

[0209] <p>“These trials using GPRS core network solutions from NortelNetworks are a significant step in the development of TDMA-EDGE andunderscore the rapid progress industry is making”, said Roderick Nelson,chief technology officer, AT&T Wireless Services. The eventual goal isto offer broadband wireless coverage to the company's customers anywherein the world, he added. </p>

[0210] <p>The companies didn't provide specifics about when the GPRSservice will be commercially available. </p> </td></tr> </table></td></tr></table> </td> </tr></table> </td></tr> <tr><td align=centervalign=top> <table border=0 cellpadding=0><tr> <td> </td></tr></table></td></tr> </table </td> <td align=Left valign=Center> <table border=0cellpadding=0><tr> <td> </td></tr></table> </td> </tr></table></body></html>

[0211] Appendix 3—Resulting Page Sent to an Internet-Enabled MobilePhone <?xml version=“1.0”?><!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML1.1//EN” “http://www.wapforum.org/DTD/wml_1.1.xml”> <wml><card> <tablealign=“center” columns=“2”><tr> <td> <p> <a href=“TestPortal.jsp”> <imgsrc=“images/stars10.bmp”/> </a> </p> </td> <td> <b>volantis</b> </td></tr></table> <p><em><a href=“list1tmp1475618599.wml”>CompanyNews</a></em></p> <p><em><a href=“list1tmp1484083075.wml”>HeadlineNews</a></em></p> <p><a href=“LoginForm.jsp”>Please log in</a></p></card></wml>

[0212] Appendix 4—The Deck Generated Automatically to Hold the CompanyNews <?xml version=“1.0”?><!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML1.1//EN“httpd://www.wapforum.org/DTD/wml_1.1.xml”> <wml><card> <p><em><ahref=list2tmp302605028.wml”>Informix Upgrades Java Database</a></em></p><p><em><a href=list2tmp299142288.wml”>AT&amp;T Wireless, Nortel to TrialGPRS</a></em></p> </card></wml>

[0213] Appendix 5—The Deck Generated Automatically to Hold the StoryAbout AT&T <?xml version=“1.0”?><!DOCTYPE wml PUBLIC “-//WAPFORUM//DTDWML 1.1//EN“ ”httpd://www.wapforum.org/DTD/wml_1.1.xml”> <wml><card>

[0214] <p><em>AT&amp;T Wireless, Nortel to TrialGPRS</em></p><p>AT&azp;T Wireless Services (NYSE: AWE) and NortelNetworks (NYSE/TSE: NT) say they will start testing broader-band GeneralPacket Radio Service (GPRS) in the U.S. this summer and are workingtoward the eventual delivery of faster third-generation (3G) service.</p>

[0215] <p>The GPRS tests will begin in several unnamed major U.S. citiesthis summer, the companies said in an announcement. The companies areworking together to eventually introduce full 3G TDMLA-EDGE technology.</p>

[0216] <p>&quot;These trials using GPRS core network solutions fromNortel Networks are a significant step in the development of TDMA-EDGEand underscore the rapid progress industry is making&quot;, saidRoderick Nelson, chief technology officer, AT&amp;T Wireless Services.The eventual goal is to offer broadband wireless coverage to thecompany&apos;s customers anywhere in the world, he added. </p>

[0217] <p>The companies didn&apos;t provide specifics about when theGPRS service will be commercially available. </p>

[0218] </card></wml>

1. Apparatus for responding to a request message from a remote userdevice for web page information by generating web page code capable ofbeing interpreted by the user device for displaying one or more webpages and for outputting a response message comprising the web pagecode, the apparatus comprising: extracting means for extracting from therequest message information determining a device type identifieridentifying the remote user device as being one of a set of possibledevice types having different capabilities; a processor for operating acode generating engine to generate the web page code; first memory meansfor storing the web page information as a content document comprising aset of instructions written in a script language for generating the webpage code; and second memory means for storing device dependentinformation for each of the set of different device types; wherein thecode generating engine comprises interpreting means for interpreting theinstructions with reference to selected device dependent informationcorresponding to the device type identifier, the code generating enginethereby being operable to generate the web page code in a form in whichthe web page code is tailored to the remote user device.
 2. Apparatus asclaimed in claim 1, wherein the script language comprises a first markup language.
 3. Apparatus as claimed in claim 2, wherein the contentdocument comprises content code defining information to be displayed andpredefined tags for controlling the presentation of the information tobe displayed; wherein the interpreting means is operable to interpreteach tag with reference to the selected device dependent information. 4.Apparatus as claimed in claim 3, wherein the device dependentinformation is stored as a set of tables and wherein the devicedependent information is assimilated in a set of objects accessible tothe tags in a run time environment of the code generating engine. 5.Apparatus as claimed in claim 4, wherein the run time environmentcomprises a JAVA virtual machine and the set of objects comprise JAVAbeans.
 6. Apparatus as claimed in any of claims 4 and 5, wherein thetables are in hierarchical form defining a hierarchical tree in whichnodes correspond to respective device types in successive hierarchicallayers.
 7. Apparatus as claimed in claim 6, wherein each device typenode is represented by respective entries in each of the tables todefine those attributes of the device type which differ from attributesof a parent node from which the device type node branches.
 8. Apparatusas claimed in any of claims 4 to 7, wherein the set of tables comprisesa device policy table defining technical attributes of each device type.9. Apparatus as claimed in any of claims 4 to 8, wherein the set oftables comprises a protocol policy table defining the format of the webpage code generated by the code generating engine.
 10. Apparatus asclaimed in any preceding claim wherein the web page code is generated ina second mark up language.
 11. Apparatus as claimed in claim 10,comprising means for selecting the second mark up language in accordancewith the selected device dependent information in the protocol policytable from a number of mark up languages comprising at least HTML andWML.
 12. Apparatus as claimed in any of claims 4 to 11, wherein the setof tables comprises a style policy table defining the style ofpresentation of the web page information.
 13. Apparatus as claimed inclaim 12, wherein the style policy table defines attributes including atleast one of: (a) font attributes; (b) colour; and (c) background. 14.Apparatus as claimed in any of claims 4 to 13, wherein the set of tablescomprises a themes policy table defining at least one of (a) decorativefeatures; and (b) a logo.
 15. Apparatus as claimed in any of claims 4 to14, wherein the set of tables comprises a layout policy table definingfor each device type the layout of the web page information with respectto a display area of each device type.
 16. Apparatus as claimed in claim15, wherein the layout policy table defines the layout with reference toa set of panes comprising portions of the display area and containingrespective portions of the web page information.
 17. Apparatus asclaimed in claim 16, wherein the layout police determines for eachdevice type the number and configuration of panes.
 18. Apparatus asclaimed in claim 17 wherein, for a device type having minimal screenarea, the layout policy determines the configuration of pages to be aset of decks comprising single panes for use in displaying the web pageinformation by displaying the decks successively.
 19. Apparatus asclaimed in any of claims 4 to 18, wherein the content code comprises atleast one component name identifying a respective data component, andwherein the apparatus comprises a data structure in which at least onedata component exists as a set of data objects defining multipleversions of the data component where the data objects have differentdata properties suited to different remote user devices.
 20. Apparatusas claimed in claim 19, comprising means for selecting a data objectfrom the set of data objects identified by a component name forinclusion in the web page code on the basis of the device typeidentifier.
 21. Apparatus as claimed in claim 20, wherein the selectingmeans comprises a component policy table for looking up a predeterminedselection of data object.
 22. Apparatus as claimed in claim 20, whereinthe selection means is operable to determine the technical attributes ofthe remote user device and to select the data object by comparing thetechnical attributes with data properties of each data object. 23.Apparatus as claimed in claim 22, wherein the selection means isoperable to determine the technical attributes by referring to a devicepolicy table.
 24. Apparatus as claimed in any of claims 22 and 23,wherein the data objects are stored in a data structure in whichmetadata is stored in association with each data object and wherein thedata properties of each data object are defined by respective metadata.25. Apparatus as claimed in any of claims 16 to 18, comprising agraphical user interface for receiving user input and document authoringmeans responsive to the graphical user interface for creating documentsof the web page generating instructions.
 26. Apparatus as claimed inclaim 25, wherein the authoring means comprises means for receivingdata, and data conversion means for converting the data into a set ofdata objects each containing a respective version of the data suited totechnical attributes of a respective device type.
 27. Apparatus asclaimed in claim 26, wherein the set of data objects further comprisesmultiple versions corresponding to a set of available user preferences.28. Apparatus as claimed in claim 27, comprising means for determining auser preference from the request message and wherein the selecting meansis further operable to select the data object according to the userpreference.
 29. Apparatus as claimed in claim 28, wherein the multipleversions comprise versions in each of a set of languages and wherein theuser preference comprises a preferred language.
 30. Apparatus as claimedin any preceding claim, comprising: code measuring means for measuringthe amount of code representative of a page generated by the codegenerating engine; determining means for determining whether thetechnical attributes of the user device include sufficient data capacityto accommodate the measured amount of code, and means responsive to anegative determination for dividing the code into two or more portionsof code such that each portion is representative of a respective portionof the page and comprises an amount of code within the data capacity ofthe user device.
 31. Apparatus as claimed in claim 30 when dependentfrom claim 8, wherein the determining means is operable to determine thetechnical attributes by referring to the device policy table. 32.Apparatus as claimed in any of claims 30 and 31, comprising a buffermemory for storing the portions of code for subsequent transmission tothe user device.
 33. Apparatus as claimed in claim 32, comprising asession memory for storing client data received in successive messagesfrom the user device in response to successive transmissions of therespective portions of code representing portions of the pane, and meansfor combining as a single data object client data for a completedsession in which client data is received responsive to all of theportions of the pane.
 34. Apparatus as claimed in claim 33, wherein thepane defines a form and wherein the portions of the pane compriserespective data fields of the form.
 35. Apparatus as claimed in any ofclaims 4 to 18, wherein the set of tables comprises a dynamic policytable defining code generating attributes which are determined accordingto the values of time varying parameters.
 36. Apparatus as claimed inclaim 35, wherein the code generating attributes define image content ofthe web page code and the time varying parameter is the bandwidthavailable for communication with the device.
 37. Apparatus as claimed inany preceding claim, comprising a cache memory operable to store a copyof web page code output in a response message; and means for outputtingweb page code from the stored copy in response to receiving a furtherrequest message for the same web page information.
 38. Apparatus asclaimed in claim 37, wherein the cache memory is operable to selectivelystore web page code depending upon whether a requirement for cachememory storage is defined in the content document from which the webpage code is generated.
 39. Apparatus as claimed in claim 38, whereinthe requirement for cache memory storage is set by operation of a taginserted in the content document.
 40. Apparatus as claimed in claim 39,wherein the tag further defines a duration of validity of the copy ofweb page code stored in cache memory.
 41. Apparatus as claimed in anypreceding claim, wherein the extracting means is operable to extractidentification information from a header of the request message and todetermine the device type identifier by referring to a table of devicetype identifiers for which device dependent information is stored in thesecond memory means.
 42. Apparatus as claimed in claim 41, wherein theextracting means is operable to determine from the table, for theidentification information obtained from the header, whether acorresponding device type identifier is available and, if not, togenerate an indication that the user device is unrecognised. 43.Apparatus as claimed in claim 42, comprising probe means responsive tothe indication that the user device is unrecognised to send a probeagent to the user device for extracting device information, and meansfor receiving a response message containing the device information fromthe user device.
 44. Apparatus as claimed in claim 43, comprising meansfor comparing the received device information with stored devicedependent information for known devices and means for determining adevice type identifier corresponding to a best match between the devicedependent information for known devices and the device information forthe unrecognised device.
 45. Apparatus as claimed in claim 44, whereinthe code generating engine is operable to generate web page code usingthe device type identifier of the known device determined to be a bestmatch to the unrecognised device.
 46. Apparatus as claimed in anypreceding claim, further comprising: receiving means for receiving therequest message via a network to which the apparatus is connected inuse; and output means for outputting the response message comprising theweb page code to the user device via the network to which the apparatusis connected in use.
 47. Apparatus as claimed in any preceding claim,comprising means for selecting the web page information from the firstmemory means according to the content of the request message and meansfor inputting the web page information and the device type identifier tothe code generating engine.
 48. A method of responding to a requestmessage from a remote user device for web page information by generatingweb page code capable of being interpreted by the user device fordisplaying one or more web pages and for outputting a response messagecomprising the web page code, the method comprising: extracting from therequest message information determining a device type identifieridentifying the remote user device as being one of a set of possibledevice types having different capabilities; operating a code generatingengine to generate the web page code; storing the web page informationin a first memory means as a content document comprising a set ofinstructions written in a script language for generating the web pagecode; and storing device dependent information for each of the set ofdifferent device types in a second memory means; wherein the codegenerating engine interprets the instructions with reference to selecteddevice dependent information corresponding to the device typeidentifier, the code generating engine thereby generating the web pagecode in a form in which the web page code is tailored to the remote userdevice.
 49. A method as claimed in claim 48, wherein the script languagecomprises a first mark up language.
 50. A method as claimed in claim 49,wherein the content document comprises content code defining informationto be displayed and predefined tags for controlling the presentation ofthe information to be displayed; wherein the interpreting meansinterprets each tag with reference to the selected device dependentinformation.
 51. A method as claimed in claim 50, wherein the devicedependent information is stored as a set of tables and wherein thedevice dependent information is assimilated in a set of objectsaccessible to the tags in a run time environment of the code generatingengine.
 52. A method as claimed in claim 51, wherein the run timeenvironment comprises a JAVA virtual machine and the set of objectscomprise JAVA beans.
 53. A method as claimed in any of claims 51 and 52,wherein the tables are in hierarchical form defining a hierarchical treein which nodes correspond to respective device types in successivehierarchical layers.
 54. A method as claimed in claim 53, wherein eachdevice type node is represented by respective entries in each of thetables to define those attributes of the device type which differ fromattributes of a parent node from which the device type node branches.55. A method as claimed in any of claims 51 to 54, wherein the set oftables comprises a device policy table defining technical attributes ofeach device type.
 56. A method as claimed in any of claims 51 to 55,wherein the set of tables comprises a protocol policy table defining theformat of the web page code generated by the code generating engine. 57.A method as claimed in any of claims 48 to 56 wherein the web page codeis generated in a second mark up language.
 58. A method as claimed inclaim 57, comprising means for selecting the second mark up language inaccordance with the selected device dependent information in theprotocol policy table from a number of mark up languages comprising atleast HTML and WML.
 59. A method as claimed in any of claims 51 to 58,wherein the set of tables comprises a style policy table defining thestyle of presentation of the web page information.
 60. A method asclaimed in claim 59, wherein the style policy table defines attributesincluding at least one of: (a) font attributes; (b) colour; and (c)background.
 61. A method as claimed in any of claims 51 to 60, whereinthe set of tables comprises a themes policy table defining at least oneof (a) decorative features; and (b) a logo.
 62. A method as claimed inany of claims 51 to 61, wherein the set of tables comprises a layoutpolicy table defining for each device type the layout of the web pageinformation with respect to a display area of each device type.
 63. Amethod as claimed in claim 62, wherein the layout policy table definesthe layout with reference to a set of panes comprising portions of thedisplay area and containing respective portions of the web pageinformation.
 64. A method as claimed in claim 63, wherein the layoutpolicy determines for each device type the number and configuration ofpanes.
 65. A method as claimed in claim 64 wherein, for a device typehaving minimal screen area, the layout policy determines theconfiguration of pages to be a set of decks comprising single panes foruse in displaying the web page information by displaying the deckssuccessively.
 66. A method as claimed in any of claims 51 to 65, whereinthe content code comprises at least one component name identifying arespective data component, and wherein the method comprises accessing adata structure in which at least one data component exists as a set ofdata objects defining multiple versions of the data component where thedata objects have different data properties suited to different remoteuser devices.
 67. A method as claimed in claim 66, comprising a step ofselecting a data object from the set of data objects identified by acomponent name for inclusion in the web page code on the basis of thedevice type identifier.
 68. A method as claimed in claim 67, wherein theselecting step comprises accessing a component policy table for lookingup a predetermined selection of data object.
 69. A method as claimed inclaim 67, wherein the selection step determines the technical attributesof the remote user device and selects the data object by comparing thetechnical attributes with data properties of each data object.
 70. Amethod as claimed in claim 69, wherein the selection step determines thetechnical attributes by referring to a device policy table.
 71. A methodas claimed in any of claims 69 and 70, wherein the data objects arestored in a data structure in which metadata is stored in associationwith each data object and wherein the data properties of each dataobject are defined by respective metadata.
 72. A method as claimed inany of claims 63 to 65, comprising receiving user input via a graphicaluser interface and operating a document authoring means responsive tothe graphical user interface for creating documents of the web pagegenerating instructions.
 73. A method as claimed in claim 72, comprisingthe steps of receiving data, and converting the data into a set of dataobjects each containing a respective version of the data suited totechnical attributes of a respective device type.
 74. A method asclaimed in claim 73, wherein the set of data objects further comprisesmultiple versions corresponding to a set of available user preferences.75. A method as claimed in claim 74, comprising means for determining auser preference from the request message and wherein the selecting meansis further operable to select the data object according to the userpreference.
 76. A method as claimed in claim 75, wherein the multipleversions comprise versions in each of a set of languages and wherein theuser preference comprises a preferred language.
 77. A method as claimedin any of claims 48 to 76, comprising the steps of: measuring the amountof code representative of a page generated by the code generatingengine; determining whether the technical attributes of the user deviceinclude sufficient data capacity to accommodate the measured amount ofcode, and, in response to a negative determination, dividing the codeinto two or more portions of code such that each portion isrepresentative of a respective portion of the page and comprises anamount of code within the data capacity of the user device.
 78. A methodas claimed in claim 77 when dependent from claim 55, wherein thedetermining step determines the technical attributes by referring to thedevice policy table.
 79. A method as claimed in any of claims 77 and 78,comprising storing the portions of code in a buffer memory forsubsequent transmission to the user device.
 80. A method as claimed inclaim 79, comprising storing in a session memory client data received insuccessive messages from the user device in response to successivetransmissions of the respective portions of code representing portionsof the page, and combining as a single data object client data for acompleted session in which client data is received responsive to all ofthe portions of the page.
 81. A method as claimed in claim 80, whereinthe page defines a form and wherein the portions of the page compriserespective data fields of the form.
 82. A method as claimed in any ofclaims 51 to 65, wherein the set of tables comprises a dynamic policytable defining code generating attributes which are determined accordingto the values of time varying parameters.
 83. A method as claimed inclaim 82, wherein the code generating attributes define image content ofthe web page code and the time varying parameter is the bandwidthavailable for communication with the device.
 84. A method as claimed inany of claims 48 to 83, comprising storing in a cache memory a copy ofweb page code output in a response message; and outputting web page codefrom the stored copy in response to receiving a further request messagefor the same web page information.
 85. A method as claimed in claim 84,wherein the cache memory selectively stores web page code depending uponwhether a requirement for cache memory storage is defined in the contentdocument from which the web page code is generated.
 86. A method asclaimed in claim 85, wherein the requirement for cache memory storage isset by operation of a tag inserted in the content document.
 87. A methodas claimed in claim 86, wherein the tag further defines a duration ofvalidity of the copy of web page code stored in cache memory.
 88. Amethod as claimed in any of claims 48 to 87, wherein the extracting stepextracts identification information from a header of the request messageand determines the device type identifier by referring to a table ofdevice type identifiers for which device dependent information is storedin the second memory means.
 89. A method as claimed in claim 88, whereinthe extracting step determines from the table, for the identificationinformation obtained from the header, a corresponding device typeidentifier is available and, if not, generates an indication that theuser device is unrecognised.
 90. A method as claimed in claim 89,comprising actuating a probe means in response to the indication thatthe user device is unrecognised to send a probe agent to the user devicefor extracting device information, and receiving a response messagecontaining the device information from the user device.
 91. A method asclaimed in claim 90, comprising comparing the received deviceinformation with stored device dependent information for known devicesand determining a device type identifier corresponding to a best matchbetween the device dependent information for known devices and thedevice information for the unrecognised device.
 92. A method as claimedin claim 91, wherein the code generating engine generates web page codeusing the device type identifier of the known device determined to be abest match to the unrecognised device.
 93. A method as claimed in any ofclaims 48 to 92, further comprising: receiving the request message via anetwork; and outputting the response message comprising the web pagecode to the user device via the network.
 94. A method as claimed in anyof claims 48 to 93, comprising selecting the web page information fromthe first memory means according to the content of the request messageand inputting the web page information and the device type identifier tothe code generating engine.
 95. A method of responding to a requestmessage from a remote user device for web page information by generatingweb page code capable of being interpreted by the user device fordisplaying one or more web pages and for outputting a response messagecomprising the web page code, the method comprising: determining adevice type identifier identifying the remote user device as being oneof a set of possible device types having different capabilities;operating a code generating engine to generate the web page code;storing the web page information in a first memory means as a contentdocument comprising a set of instructions for generating the web pagecode; and storing device dependent information for each of the set ofdifferent device types in a second memory means; wherein the contentcode comprises at least one component name identifying a respective datacomponent for inclusion in the web page code, and comprising the step ofaccessing a data structure in which the data component exists as a setof data objects defining multiple versions of the data component wherethe data objects have different data properties suited to differentremote user devices; and selecting a data object from the set of dataobjects identified by a component name for inclusion in the web pagecode on the basis of the device type identifier.
 96. A method as claimedin claim 95, wherein the selecting step comprises accessing a componentpolicy table for looking up a predetermined selection of data object.97. A method as claimed in claim 95, wherein the selection stepdetermines the technical attributes of the remote user device on thebasis of the device type identifier and selects the data object bycomparing the technical attributes with data properties of each dataobject.
 98. A method as claimed in claim 97, wherein the selection stepdetermines the technical attributes by referring to a device policytable.
 99. A method as claimed in any of claims 97 and 98, wherein thedata objects are stored in a hierarchical data structure in whichmetadata is stored in association with each data object and wherein thedata properties of each data object are defined by respective metadata.100. A method as claimed in claim 26, wherein the set of data objectsfurther comprises multiple versions corresponding to a set of availableuser preferences; and further comprising: determining a user preferencefrom the request message whereby the selecting step selects the dataobject according to the user preference.
 101. A method as claimed inclaim 100, wherein the multiple versions comprise versions in each of aset of languages and wherein the user preference comprises a preferredlanguage.
 102. A data structure in which data objects are accessible ina hierarchy on which different hierarchical levels contain differentversions of a data component corresponding to respective levels oftechnical capabilities of user devices to which the data objects are tobe provided.
 103. A method of processing data for storage in readinessfor being output to one of a number of possible user devices havingdifferent technical capabilities, the method comprising: receiving adata element; generating a set of data objects from the data elementsuch that each data object comprises a respective version of datacontained in the data element, and storing the set of data objects in ahierarchical data structure in which different levels correspond torespective technical capabilities of user devices.
 104. Apparatus forresponding to a request message from a remote user device for web pageinformation by generating web page code capable of being interpreted bythe user device for displaying one or more web pages and for outputtinga response message comprising the web page code, the apparatuscomprising: extracting means for extracting from the request messageinformation determining a device type identifier identifying the remoteuser device as being one of a set of possible device types havingdifferent capabilities; a processor for operating a code generatingengine to generate the web page code; the code generating engine beingoperable in response to the device type identifier using devicedependent information to generate the web page code in a form in whichthe web page code is tailored to the remote user device; wherein theextracting means is operable to extract identification information froma header of the request message and to determine the device typeidentifier by referring to a table of device type identifiers; theapparatus further comprising probe means responsive to the indicationthat the user device is unrecognised to send a probe agent to the userdevice for extracting device information, and means for receiving aresponse message containing the device information from the user device.105. Apparatus as claimed in claim 104, comprising means for comparingthe received device information with stored device dependent informationfor known devices and means for determining a device type identifiercorresponding to a best match between the device dependent informationfor known devices and the device information for the unrecogniseddevice.
 106. Apparatus as claimed in claim 105, wherein the codegenerating engine is operable to generate web page code using the devicetype identifier of the known device determined to be a best match to theunrecognised device.
 107. A method of responding to a request messagefrom a remote user device for web page information by generating webpage code capable of being interpreted by the user device for displayingone or more web pages and for outputting a response message comprisingthe web page code, the method comprising: extracting from the requestmessage information determining a device type identifier identifying theremote user device as being one of a set of possible device types havingdifferent capabilities; operating a code generating engine to generatethe web page code; the code generating engine being operated in responseto the device type identifier using device dependent information togenerate the web page code in a form in which the web page code istailored to the remote user device; wherein the extracting step extractsidentification information from a header of the request message anddetermines the device type identifier by referring to a table of devicetype identifiers; the method further comprising actuating a probe meansresponsive to the indication that the user device is unrecognised tosend a probe agent to the user device for extracting device information,and receiving a response message containing the device information fromthe user device.
 108. A method as claimed in claim 107, comprisingcomparing the received device information with stored device dependentinformation for known devices and determining a device type identifiercorresponding to a best match between the device dependent informationfor known devices and the device information for the unrecogniseddevice.
 109. A method as claimed in claim 108, wherein the codegenerating engine is generates web page code using the device typeidentifier of the known device determined to be a best match to theunrecognised device.
 110. A computer program comprising processorimplementable instructions for controlling a processor for carrying outthe method of any one of claims 48 to 101, 103, and 107 to
 109. 111. Astorage medium storing processor implementable instructions forcontrolling a processor to carry out the method of any one of claims 48to 101, 103 and 107 to
 109. 112. An electrical signal carrying processorimplementable instructions for controlling a processor to carry out themethod of any one of claims 48 to 101, 103 and 107 to
 109. 113. A codegenerating engine for use in an apparatus of any of claims 1 to
 47. 114.A storage medium storing a set of policy tables for use in a method asclaimed in any one of claims 48 to
 94. 115. A storage medium storing aset of tags for use in a method as claimed in any one of claims 48 to94.